The use of Digital Certificates must be implemented in accordance with security requirements.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-3225	ITNT0040	SV-3225r3_rule	DCCS-1 DCCS-2 ECCD-1 ECCD-2	Medium

Description
Digital certificates are a primary requirement for Secure Sockets Layer (i.e., SSL). The origin of a certificate, the Certificate Authority (i.e., CA), is crucial in determining if the certificate should be trusted. Failure to maintain a list of appropriate host-based CA certificates could result in unauthorized access to the host. Certificate name filtering is a facility that allows multiple certificates to be mapped to a single ACP userid. Rather than matching a certificate stored in the ACP to determine the userid, criteria rules are used. Depending on the filter criteria, a large number of client certificates could be mapped to a single userid. Failure to properly control the use of certificate name filtering could result in the loss of individual identity and accountability.

Description

Digital certificates are a primary requirement for Secure Sockets Layer (i.e., SSL). The origin of a certificate, the Certificate Authority (i.e., CA), is crucial in determining if the certificate should be trusted. Failure to maintain a list of appropriate host-based CA certificates could result in unauthorized access to the host. Certificate name filtering is a facility that allows multiple certificates to be mapped to a single ACP userid. Rather than matching a certificate stored in the ACP to determine the userid, criteria rules are used. Depending on the filter criteria, a large number of client certificates could be mapped to a single userid. Failure to properly control the use of certificate name filtering could result in the loss of individual identity and accountability.

STIG	Date
z/OS ACF2 STIG	2016-01-04

Details

Check Text ( C-35842r2_chk )
NOTE: The procedures in this checklist item presume the domain being reviewed is running all releases of z/OS, and use the ACP as the certificate store. Self-Signed Certificates If the domain being review is not a production system and is only used for test and development, this Self-Signed Certificates review can be skipped. a) From STIG ID ITCP0060, use the logonid(s) assigned to the TCP/IP address space(s) and issue the following ACF2 commands to list the certificate(s) associated with the TCPIP logonid(s): SET PROFILE(USER) DIVISION(CERTDATA) LIST LIKE(tcpip logonid.-) b) If no certificate information is found, there is NO FINDING. NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following checks. c) If the digital certificate information indicates that the issuer's distinguished name leads to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/). Examples of an acceptable DoD CA are: DoD PKI Class 3 Root CA DoD PKI Med Root CA d) If the digital certificate information indicates it is a self-signed certificate and the Status is TRUST, this is a FINDING. An example of a self-signed certificate would be site information displayed as the issuer's distinguished name. e) Using the logonid(s) assigned to the TCP/IP address space(s), issue the following ACF2 commands to list any associated key rings: SET PROFILE(USER) DIVISION(KEYRING) LIST LIKE(tcpip logonid.-) For each Certificate Owner, issue the following ACF2 commands to list the certificate(s) associated with their logonid: SET PROFILE(USER) DIVISION(CERTDATA) LIST LIKE(cert owner logonid.-) f) If the digital certificate information indicates that the issuer's distinguished name leads to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. g) If the digital certificate information indicates it is a self-signed certificate and the Status is TRUST, this is a FINDING. DoD PKI Root Certificate Authority If the domain being review is not a production system and is only used for test and development, this DoD PKI Root Certificate Authority review can be skipped. h) Issue the following ACF2 commands to list the Certificate Authorities: SET PROFILE(USER) DIVISION(CERTDATA) LIST LIKE(CERTAUTH.-) i) If no certificate information is found, there is NO FINDING. NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following checks. j) If the digital certificate information indicates that all certificates lead to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/). Examples of an acceptable DoD CA are: DoD PKI Class 3 Root CA DoD PKI Med Root CA k) If the digital certificate information indicates that any certificate is from a non-DoD entity (e.g., Verisign, Thawte, IBM World Registry) and the Status is TRUST, this is a FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/). Certificate Name Filtering l) If certificate name filtering is in use, collect documentation describing each active filter rule and written approval from the IAM to use the rule. m) Issue the following ACF2 commands to list the certificate name filters defined to ACF2: SET CONTROL(GSO) SHOW CERTMAP n) If no CERTMAP FILTERING TABLES are present, there is NO FINDING. NOTE: Certificate name filters are only valid when their Status is TRUST. Therefore, you may ignore filters with the NOTRUST status. o) If CERTMAP FILTERING TABLES are present and certificate name filters have a Status of TRUST, certificate name filtering is in use. p) If certificate name filtering is in use and filtering rules have been documented and approved by the IAM, there is NO FINDING. q) If certificate name filtering is in use and filtering rules have not been documented and approved by the IAM, this is a FINDING.

Check Text ( C-35842r2_chk )

NOTE: The procedures in this checklist item presume the domain being reviewed is running all releases of z/OS, and use the ACP as the certificate store.

Self-Signed Certificates

If the domain being review is not a production system and is only used for test and development, this Self-Signed Certificates review can be skipped.

a) From STIG ID ITCP0060, use the logonid(s) assigned to the TCP/IP address space(s) and issue the following ACF2 commands to list the certificate(s) associated with the TCPIP logonid(s):

SET PROFILE(USER) DIVISION(CERTDATA)
LIST LIKE(tcpip logonid.-)

b) If no certificate information is found, there is NO FINDING.

NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following checks.

c) If the digital certificate information indicates that the issuer's distinguished name leads to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

Examples of an acceptable DoD CA are:
DoD PKI Class 3 Root CA
DoD PKI Med Root CA

d) If the digital certificate information indicates it is a self-signed certificate and the Status is TRUST, this is a FINDING.

An example of a self-signed certificate would be site information displayed as the issuer's distinguished name.

e) Using the logonid(s) assigned to the TCP/IP address space(s), issue the following ACF2 commands to list any associated key rings:

SET PROFILE(USER) DIVISION(KEYRING)
LIST LIKE(tcpip logonid.-)

For each Certificate Owner, issue the following ACF2 commands to list the certificate(s) associated with their logonid:

SET PROFILE(USER) DIVISION(CERTDATA)
LIST LIKE(cert owner logonid.-)

f) If the digital certificate information indicates that the issuer's distinguished name leads to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING.

g) If the digital certificate information indicates it is a self-signed certificate and the Status is TRUST, this is a FINDING.

DoD PKI Root Certificate Authority

If the domain being review is not a production system and is only used for test and development, this DoD PKI Root Certificate Authority review can be skipped.

h) Issue the following ACF2 commands to list the Certificate Authorities:

SET PROFILE(USER) DIVISION(CERTDATA)
LIST LIKE(CERTAUTH.-)

i) If no certificate information is found, there is NO FINDING.

NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following checks.

j) If the digital certificate information indicates that all certificates lead to a DoD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA), there is NO FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

Examples of an acceptable DoD CA are:
DoD PKI Class 3 Root CA
DoD PKI Med Root CA

k) If the digital certificate information indicates that any certificate is from a non-DoD entity (e.g., Verisign, Thawte, IBM World Registry) and the Status is TRUST, this is a FINDING. Reference the IASE website for complete information as to which certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

Certificate Name Filtering

l) If certificate name filtering is in use, collect documentation describing each active filter rule and written approval from the IAM to use the rule.

m) Issue the following ACF2 commands to list the certificate name filters defined to ACF2:

SET CONTROL(GSO)
SHOW CERTMAP

n) If no CERTMAP FILTERING TABLES are present, there is NO FINDING.

NOTE: Certificate name filters are only valid when their Status is TRUST. Therefore, you may ignore filters with the NOTRUST status.

o) If CERTMAP FILTERING TABLES are present and certificate name filters have a Status of TRUST, certificate name filtering is in use.

p) If certificate name filtering is in use and filtering rules have been documented and approved by the IAM, there is NO FINDING.

q) If certificate name filtering is in use and filtering rules have not been documented and approved by the IAM, this is a FINDING.

Fix Text (F-31095r2_fix)
The IAO must ensure that for production environments, the list of Certificate Authorities considered trusted by the z/OS host are limited to those with a trust hierarchy that leads to a DOD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA). The information on IASE website must be reviewed to ensure that certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/). The IAO must ensure that for production environments, self-signed certificates are not used. Certificate name filtering is a facility that allows multiple certificates to be mapped to a single ACP ID. Rather than matching a certificate stored in the ACP to look up an ID, certificate name filtering uses criteria rules stored in the ACP. A filter rule uses parts of the distinguished name of the certificate owner and/or issuer (CA) to determine an ID to assign to the user. Depending on the filter criteria, a large number of client certificates could map to a single ID. The IAO must ensure that certificate name filtering is not used unless the filtering rules have been documented to, and approved by, the IAM. Review the list of host-based CAs and ensure they are limited to those with a trust hierarchy that leads to a DOD PKI Root CA. Example commands to list he keyring and certdata: SET PROFILE(USER) DIVISION(KEYRING) LIST LIKE(tcpip logonid.-) SET PROFILE(USER) DIVISION(CERTDATA) LIST LIKE(cert owner logonid.-) Ensure any certificate name filtering rules in use are documented and approved by the IAM.

Fix Text (F-31095r2_fix)

The IAO must ensure that for production environments, the list of Certificate Authorities considered trusted by the z/OS host are limited to those with a trust hierarchy that leads to a DOD PKI Root Certificate Authority or EXTERNAL CERTIFICATION AUTHORITY(ECA). The information on IASE website must be reviewed to ensure that certificates are acceptable (http://iase.disa.mil/pki-pke/interoperability/).

The IAO must ensure that for production environments, self-signed certificates are not used.

Certificate name filtering is a facility that allows multiple certificates to be mapped to a single ACP ID. Rather than matching a certificate stored in the ACP to look up an ID, certificate name filtering uses criteria rules stored in the ACP. A filter rule uses parts of the distinguished name of the certificate owner and/or issuer (CA) to determine an ID to assign to the user. Depending on the filter criteria, a large number of client certificates could map to a single ID.

The IAO must ensure that certificate name filtering is not used unless the filtering rules have been documented to, and approved by, the IAM.

Review the list of host-based CAs and ensure they are limited to those with a trust hierarchy that leads to a DOD PKI Root CA.

Example commands to list he keyring and certdata:

SET PROFILE(USER) DIVISION(KEYRING)
LIST LIKE(tcpip logonid.-)

SET PROFILE(USER) DIVISION(CERTDATA)
LIST LIKE(cert owner logonid.-)

Ensure any certificate name filtering rules in use are documented and approved by the IAM.